7 Abschluss & Ausblick: Von Werkzeugnutzung zu Lehrarchitektur

„Gute Lehre endet nicht mit dem Foliensatz.
Sie beginnt dort, wo andere ihn weiterdenken können.“

Dieses Buch hat einen klaren Anspruch verfolgt: nicht möglichst viele KI-Tools vorzustellen, sondern einen nachvollziehbaren, überprüfbaren Workflow für Hochschullehre zu entwickeln. Einen Workflow, der akademische Standards respektiert, didaktische Qualität ernst nimmt und gleichzeitig realistisch im Hochschulalltag einsetzbar ist.

Wenn Sie die vorherigen Kapitel lesen, wird deutlich:
Es geht nicht um „KI in der Lehre“, sondern um Lehre mit Struktur – und KI als Beschleuniger dieser Struktur.

7.1 Die Essenz in einem Bild (ohne Bild)

Der Workflow lässt sich auf drei Ebenen verdichten:

Epistemische Ebene
Was gilt als Wissen?
→ Recherche mit Perplexity, Grounding mit NotebookLM
Didaktische Ebene
Was sollen Studierende lernen, können, reflektieren?
→ Transformation mit Gemini/ChatGPT
Mediale Ebene
Wie wird das Lernen zugänglich, überprüfbar, skalierbar?
→ MARP, Quarto/H5P, HeyGen

Die entscheidende Erkenntnis ist dabei fast banal – und genau deshalb wirksam:

Nicht jedes Tool ist für jede Phase geeignet. Qualität entsteht durch Arbeitsteilung.

Akademische Qualität entsteht dort, wo Recherche, Didaktik und Medien bewusst getrennt – und danach sauber verbunden werden.

7.2 Was sich mit diesem Workflow ändert (und was nicht)

Was sich nicht ändert: - Sie bleiben verantwortlich für Inhalte. - Sie bleiben verantwortlich für Prüfungen. - Sie bleiben verantwortlich für didaktische Entscheidungen.

Was sich ändert: - Vorbereitung wird reproduzierbar statt einmalig. - Materialien werden weiterentwickelbar statt statisch. - Lehre wird teilbar statt isoliert.

Damit kommen wir zum Ausblick.

7.3 Ausblick 1: Versionskontrolle mit Git – ohne Technikpanik

Das Wort „Git“ löst bei vielen Kolleg:innen reflexartig Abwehr aus. Das ist verständlich – und in 90 % der Fälle unnötig.

Man muss Git nicht verstehen, um es sinnvoll zu nutzen.

Didaktisch gedacht ist Git nichts anderes als: - eine Versionshistorie („Was war letzte Woche anders?“) - eine Rückgängig-Taste auf Steroiden - eine Dokumentation von Entwicklung

Für Lehrmaterialien bedeutet das: - Kein „final_final_v3_neu.pdf“ mehr - Änderungen sind nachvollziehbar - Alte Versionen gehen nie verloren

Niedrigschwellige Realität:
Viele nutzen Git bereits – ohne es zu merken.
(z. B. über GitHub Desktop oder Web-Oberflächen)

7.4 Ausblick 2: Automatisiertes Deployment – „Veröffentlichen ohne Klickorgien“

Ein häufiges Problem in der Lehre ist nicht das Erstellen von Material, sondern dessen Verteilung: - Wo liegt die aktuelle Version? - Ist das Moodle-Dokument noch korrekt? - Warum sieht die HTML-Seite anders aus als gestern?

Hier kommen automatisierte Abläufe ins Spiel – z. B. über GitHub Actions.
Der Kern ist einfach erklärt:

Wenn sich der Inhalt ändert, aktualisiert sich die Webseite automatisch.

Keine Serverkenntnisse, kein nächtliches Hochladen.
Ein Commit (eine Änderung) genügt – der Rest passiert im Hintergrund.

Für Kolleg:innen heißt das: - Eine feste URL für ein Skript oder Buch - Immer die aktuelle Version online - Keine manuelle Pflege mehr

Und ja: Das klingt technisch.
In der Praxis ist es oft weniger Arbeit als Moodle-Updates.

7.5 Ausblick 3: Co-Creation mit Kolleg:innen – Pull Requests ohne Angst

Der vielleicht größte didaktische Hebel liegt nicht in der Technik, sondern in der Zusammenarbeit.

Stellen Sie sich vor: - Eine Kollegin ergänzt ein Beispiel. - Ein Kollege korrigiert eine Definition. - Studierende schlagen eine verständlichere Erklärung vor.

All das ist möglich – über sogenannte Pull Requests.
Der komplizierte Begriff verbirgt eine einfache Idee:

Jemand macht einen Verbesserungsvorschlag,
Sie entscheiden, ob Sie ihn übernehmen.

Kein Risiko, kein Überschreiben, keine Versionskonflikte.
Das Original bleibt geschützt.

Didaktisch ist das ein Quantensprung: - Lehre wird gemeinsam entwickelt - Materialien wachsen über Semester hinweg - Expertise verteilt sich, statt zu vereinzeln

Pull Requests für Nicht-Techniker:innen

Man kann sich Pull Requests wie „Änderungsvorschläge in Word“ vorstellen – nur transparenter, sauberer und dauerhaft dokumentiert.

7.6 Ausblick 4: Wirklich gutes OER – nicht nur „frei“, sondern professionell

Offene Bildungsressourcen (OER) scheitern selten an der Lizenz.
Sie scheitern an Qualität, Pflege und Auffindbarkeit.

Der hier vorgestellte Workflow löst genau dieses Problem: - Markdown & Quarto → gut lesbar, gut pflegbar - Git → Versionsgeschichte und Attribution - Automatisches Deployment → stabile Veröffentlichung - Klare Struktur → nachnutzbar für andere

So entsteht OER, das: - nicht wie ein Nebenprodukt wirkt - nicht nach einem Semester veraltet ist - und tatsächlich Lust macht, es weiterzuverwenden

OER ist keine Ideologie.
Es ist professionelle Lehre mit offenem Ausgang.

7.7 Ein realistisches Schlusswort

Niemand erwartet, dass Sie morgen: - Git-Expert:in werden - Deployments bauen - Pull Requests managen

Der Einstieg kann klein sein: - Ein Quarto-Reader statt eines PDFs - MARP-Folien statt PowerPoint - Ein kurzes HeyGen-Video statt der zehnten identischen Erklärung

Der entscheidende Schritt ist nicht technischer Natur, sondern mental:

Lehre ist kein Produkt.
Sie ist ein Prozess – und Prozesse kann man gestalten.